Modern high performance microprocessors have an ever-increasing number of circuit elements and an ever-rising clock frequency. Also, as the number of circuits that can be used in a central processing unit (CPU) has increased, the number of parallel operations has risen. Examples of efforts to create more parallel operations include increased pipeline depth and an increase in the number of functional units in super-scalar and very-long-instruction-word architectures. As CPU performance continues to increase, the result has been a larger number of circuits switching at faster rates. Thus, from a design perspective, important considerations such as the time needed to complete a simulation and the time needed to compile a CPU design is taken into account.
As a result, high performance, massively parallel processed environments are used to perform CPU design simulation. FIG. 1 shows a block diagram of a typical computer system (100) used to control and monitor execution of a CPU design simulation. A host computer (114), with associated data store (105), controls the simulation of the CPU design that executes on a simulation hardware (116).
The host computer (114) includes such hardware and software mechanisms as are needed to manage simulation, e.g., loading execution processor code onto a processor array, transferring test interface files, transferring design symbol files, etc. The data store (105) may contain several kinds of data including hardware definition source code files, clock file data, test interface files, programmable input files, circuit “object” files, design symbol information (or design database), etc. A general purpose computer (112) with a human interface (110), such as a GUI or a command line interface, together with the host computer (114) support common functions of the simulation environment. A simulation control program (118) executes on the host computer (114) and interacts with the simulation hardware (116) via a test interface (120). The test interface (120) facilitates data transfer between the host computer (114) and the simulation hardware (116).
The simulation control program (118) controls and monitors simulations executing on the simulation hardware (116). The simulation control program (118) also allows a user to interact with the simulation (and the simulation hardware (116)) between complete simulation cycles. The simulation control program (118) supports important functions of the simulation environment (100). These functions include interactive display and modification of the simulation state, setting of execution breakpoints based on simulation times and states, use of test vector files and trace files, use of hardware definition language (HDL) modules that execute on the host computer (114). The functions are called from the simulation hardware (116), check pointing and restoration of running simulations, the generation of value change dump (VCD) files compatible with waveform analysis tools, and tracing the origin of bad signal states using backtracking techniques.
The test interface (120) supports the visibility into simulations running on the simulation hardware (116) by applying user-defined input stimuli to selected nodes in the running simulation. The output of the user-defined stimuli may be recorded as a trace of specific signals in the simulation and viewed using post-simulation analysis programs. Alternatively, the output of the user-defined stimuli may be compared to expected output values for signals in the design.
Prior to executing on the simulation hardware (116), the logic design is verified for accuracy and then compiled. During compilation, the compiler decomposes a logic design into execution processor code that may be executed in parallel on a processor array of the simulation hardware (116) by one or more execution processors. The compiler also produces routing tables and other information, such as routing processor code, control code and a design symbol file. The design symbol file involves recording physical locations where the values of nets and registers have been stored, so that test interface (120) and routines called by the simulation control program (118) may access values of nets and registers.
Compilation as described above may use a single processor compilation system as shown in FIG. 2. FIG. 2 shows a block diagram of a typical compilation system. The compilation system (130) includes compiler (134), an assembler (138), and a linker (142). The compiler (134) receives as input one or more header files (131) and various source code files (132 A, 132 B). The input files are decomposed by the compiler (134) into an assembly code (136). The assembler (138) receives as input the assembly code (136) and generates an object code (140). The linker (142) then accepts the object code as input and generates an executable file (144). Compiling the source files together, as shown in FIG. 2, results in compile times that increase substantially as the number of source files increase.